昨天最後留下了一個問題：

使用者到底會怎麼走過這些功能？

這也是我把 ClarifyBuild 的功能，從比較模糊的 Feature 往更明確的 Functional Requirement 拆完之後，才真正意識到的事。

例如，我已經可以寫出：

系統根據目前已有的 Requirement State，判斷仍有哪些重要需求資訊尚未確認。（FR-C02）

這比只寫「ClarifyBuild 要有需求釐清功能」清楚很多。

但當我把一條一條 Functional Requirement 排在一起看時，又發現了一個新的問題：

就算每個功能都寫清楚了，AI 知道這些事情應該按照什麼順序發生嗎？

Functional Requirement 還是一張張分散的卡片

延續前幾天一直使用的「活動報名網站」例子。

假設現在已經把需求寫成：

FR-01
系統應允許使用者查看活動資訊。

FR-02
系統應允許使用者填寫報名資料。

FR-03
系統應在報名資料送出後顯示報名結果。

每一條單獨看都比：

網站要有活動報名功能。

清楚很多。

但它們還是比較像一張張獨立的需求卡片。

如果直接交給 AI Coding Agent，它還是可能需要自己猜：

使用者先看到什麼？
↓
從哪裡進入報名？
↓
什麼時候填寫資料？
↓
送出之後去哪裡？
↓
怎樣才算完成報名？

如果把這些需求串成流程，就會變成：

活動詳情
↓
點擊報名
↓
填寫報名資料
↓
送出
↓
報名成功

這時候我看到的就不再只是「系統有哪些功能」，而是：

使用者實際會怎麼完成一件事情。

這就是今天想處理的 User Flow。

User Flow 到底在解決什麼？

如果只列 Feature，我可能看到：

Activity Detail
Registration Form
Submit
Success Message

如果寫成 Functional Requirement，我會更清楚每個功能應該做什麼。

但 User Flow 處理的是另一層問題：

這些功能彼此要怎麼串起來？

也就是：

使用者從哪裡開始
↓
做了什麼
↓
接著去哪裡
↓
最後完成什麼

所以我目前會先把它們簡單區分成：

Functional Requirement
回答：
「系統應該做什麼？」

↓

User Flow
回答：
「使用者怎麼完成一件事情？」

這個差異對 Vibe Coding 很重要。

因為如果我只告訴 AI：

做活動頁、報名表單、送出功能、成功提示。

AI 很可能還是得自己決定：

• 使用者從哪裡進入報名流程
• 什麼時候進入表單
• 成功後留在原頁還是跳轉
• 整個操作順序怎麼安排

而只要又進入「讓 AI 自己猜」的狀態，就可能重新出現這個系列一直在處理的問題：

AI 做出了一個合理的版本，但不一定是我真正想要的版本。

先釐清：今天畫的是哪一種 User Flow？

做到這裡時，我發現還有一個很容易混淆的地方。

ClarifyBuild 未來本來就會幫使用者整理 User Flow。

例如使用者想打造一個論文整理網站，ClarifyBuild 最後可能在 Project Specification 裡產生：

Home
↓
輸入關鍵字
↓
Search Result
↓
Paper Detail
↓
Save
↓
Collection

這是在描述：

使用者想打造的「目標專案」，它的終端使用者怎麼操作。

我暫時把它稱為：

Target Project User Flow

但今天為了真的推進 ClarifyBuild MVP，我還需要畫另一個流程：

使用者本身要怎麼操作 ClarifyBuild？

例如：

Landing
↓
輸入 Idea
↓
需求釐清
↓
確認 Scope
↓
查看 Specification
↓
取得 Coding Prompt

這是在描述 ClarifyBuild 自己怎麼被使用。

為了避免兩者混在一起，這篇文章裡我會把它稱為：

ClarifyBuild Usage Flow

兩者使用的是同一種 User Flow 思考方式，只是描述的產品主體不同。

今天主要拿 ClarifyBuild 自己當案例，因為除了理解 User Flow，也能順便把 MVP 的產品流程整理得更清楚。

Clarification Flow 又跟 User Flow 不一樣

這裡還有第三個很容易撞在一起的 Flow。

在 Day 5，我已經整理過 ClarifyBuild 的 Clarification Flow：

Idea
↓
Identify Unknowns
↓
Find Relevant Clarification Dimension
↓
Ask Clarification Question
↓
User Decision
↓
Update Requirement
↓
Check Unknowns Again

如果還有重要的 Unknown，就繼續進行下一輪。

所以它實際上是一個動態迴圈：

Identify Unknowns
↓
Find Relevant Clarification Dimension
↓
Ask Clarification Question
↓
User Decision
↓
Update Requirement
↓
Check Unknowns Again
    ├─ 還有重要 Unknown → 繼續下一輪
    └─ 沒有重要 Unknown → 進入下一階段

它回答的是：

ClarifyBuild 要怎麼判斷還缺什麼，並決定下一個問題？

這比較接近 Clarification 階段裡更細部的判斷與互動邏輯。

但今天的 ClarifyBuild Usage Flow 回答的是：

使用者怎麼走完整個 ClarifyBuild？

所以現在我會把兩者理解成：

Clarification Flow 描述需求釐清階段如何運作；Usage Flow 描述使用者如何走完整個產品。

更細部的流程，不一定都要變成 User Flow 的一個步驟

這裡也讓我修正了一個原本的想法。

一開始我曾經把 ClarifyBuild 的流程畫成：

Enter Project Idea
↓
Analyze Current Requirement
↓
Clarification Loop

但仔細想之後發現：

Analyze Current Requirement 本身其實就是 Clarification Flow 裡的：

Identify Unknowns

如果兩個都放進正式流程，就等於同一件事情出現兩次。

所以現在我會把它拆成兩個層次。

使用者看到的 Usage Flow 是：

Enter Project Idea
↓
Clarification

而進入 Clarification 之後，這個階段再展開成：

Identify Unknowns
↓
Find Relevant Clarification Dimension
↓
Ask Question
↓
User Decision
↓
Update Requirement
↓
Check Unknowns Again

也就是：

ClarifyBuild Usage Flow
↓
使用者進入 Clarification
↓
展開 Clarification Flow
↓
完成後
↓
回到 Usage Flow

這讓我多理解了一件事：

不是每一個更細部的流程，都需要變成 User Flow 裡的一個獨立步驟。

未來如果真的要在畫面上顯示：

Analyzing your idea...

那比較像一個 UI State 或 Transition。

但它和產品流程本身，是不同層次的設計問題。

先畫 Happy Path，不急著處理全部例外

開始整理 ClarifyBuild Usage Flow 之後，我很快又想到很多例外：

• 使用者按 Back 怎麼辦？
• 回去修改答案怎麼辦？
• 中途離開怎麼辦？
• localStorage 要怎麼恢復？
• 要不要有 Restart？
• Specification 可以修改嗎？
• 修改前面的答案後，後面的內容要怎麼同步？

這些問題都是真的。

但如果今天全部一起畫進去，User Flow 很快就會膨脹成一張很複雜的流程圖。

所以第一版我先只處理：

Happy Path / Main Flow

也就是使用者一路正常完成 ClarifyBuild 的主要流程。

目前整理成：

Landing
↓
Start Clarifying
↓
Enter Project Idea
↓
Clarification
↓
Review MVP Scope
↓
Confirm Requirement
↓
Generate Project Specification
↓
Spec Preview
│  └─ Export Markdown
↓
Generate AI Coding Prompt
↓
Prompt Preview
   └─ Copy Prompt

而 Clarification 這個節點，展開後就是前面已經定義好的動態 Clarification Flow。

這樣整個結構就比原本清楚很多。

User Flow 也開始幫我決定需要哪些 Pages

有了 Usage Flow 之後，我開始重新檢查 ClarifyBuild 原本規劃的頁面。

以前如果要做網站，我很容易先想：

Home
Dashboard
Result
Settings
History
Profile
...

然後再想辦法把功能塞進這些頁面。

但這次我想反過來：

Requirement
↓
User Flow
↓
Pages / Views

先知道使用者要完成什麼，再決定需要哪些畫面承接。

根據目前的 Happy Path，ClarifyBuild MVP 暫時可以收斂成四個主要 Page / View：

整理到這裡，也讓我做了兩個產品決策。

Export 不一定需要是一個 Page

原本我曾經把：

Export

也當成一個獨立頁面。

但從 User Flow 重新看之後，我開始覺得它比較像一個 Action。

例如：

Spec Preview
↓
Export Markdown

或：

Prompt Preview
↓
Copy Prompt

使用者只是想把目前看到的結果帶走，不一定需要為此再進入一個新的頁面。

所以 ClarifyBuild MVP 目前先決定：

Export 不獨立做成 Page，而是 Preview 畫面上的 Action。

Idea、Clarification、Scope 也不一定要拆成三頁

同樣地：

Idea
Clarification
Scope

是三個不同階段。

但不代表一定需要：

/idea
/clarification
/scope

三個獨立頁面。

目前比較適合第一版的方式，是讓它們都存在同一個 Builder 裡，只是呈現不同 State：

Builder
│
├─ Idea Entry State
│
├─ Clarification State
│
└─ Scope Review State

尤其 Clarification 本來就是動態的。

有些 Idea 可能缺 Target User。

有些可能已經講得很清楚。

有些需要問 Platform。

有些可能主要缺 Goal 或 Core Function。

所以目前也不適合把 Builder 硬設計成固定：

Step 1 / 7
Step 2 / 7
Step 3 / 7
...

至於 Builder 的 State 最後怎麼用 JavaScript 實作，就是之後進入 Coding 階段時要處理的問題。

Functional Requirement、User Flow、Pages 分別回答什麼？

做到這裡，我開始把三者整理成一個比較清楚的關係：

Functional Requirement
↓
系統應該做什麼？

User Flow
↓
使用者怎麼完成任務？

Pages / Views
↓
這些互動在哪裡發生？

回到活動報名網站的例子。

Functional Requirement 可能是：

系統應允許使用者提交活動報名資料。

User Flow 則是：

活動詳情
↓
點擊報名
↓
填寫資料
↓
送出
↓
報名成功

最後這些行為可能落在：

活動詳情頁
↓
報名表單
↓
成功狀態

換成 ClarifyBuild：

Functional Requirement（FR-C01）：

使用者可以輸入自己想建立的產品 Idea。

Usage Flow：

Start Clarifying
↓
Enter Project Idea
↓
Submit

對應到：

Builder

另一條需求：

系統應將確認後的 Requirement 整理成 Project Specification。

Usage Flow：

Confirm Requirement
↓
Generate Project Specification
↓
Review Result

對應到：

Spec Preview

到這裡之後，Requirement 就不再只是一條條獨立文字。

它開始和：

使用者行為、流程順序、產品畫面

真正連在一起。

但今天還不急著畫 Wireframe

整理出 Pages 之後，我已經很容易開始想：

• Input 要放哪裡？
• Continue 按鈕長怎樣？
• Clarification Question 怎麼排版？
• Progress 要不要顯示？
• Builder 要不要左右雙欄？
• Spec Preview 怎麼呈現？
• Copy Prompt 按鈕放哪裡？

但這些已經開始進入 Wireframe 和 UI Design。

今天我想先停在：

Requirement
↓
User Flow
↓
Pages / Views

先確認：

使用者要做什麼、怎麼走、這些事情在哪裡發生。

至於：

畫面到底長什麼樣子？

等後面真的進入 Wireframe 時再處理。

不然我很可能又回到以前的習慣：

流程還沒想清楚，就開始設計畫面。

文章探索順序，不等於 ClarifyBuild 最後的正式流程

還有一點需要特別記下來。

昨天 Day 7 我先研究 Functional Requirement。

今天 Day 8 才開始研究 User Flow。

所以如果只看文章順序，很容易變成：

Functional Requirement
↓
User Flow
↓
Pages

這只是這 30 天 Build Log 的探索順序，跟 ClarifyBuild 未來正式產生 Specification 時實際執行的順序，可能不會完全一樣。

這 30 天文章記錄的是：

我打造 ClarifyBuild 時，怎麼一步一步發現問題。

目前的探索過程比較像：

先整理 Feature
↓
發現 Feature 太模糊
↓
開始寫 Functional Requirement
↓
Requirement 寫完
↓
又發現功能之間缺少順序
↓
開始研究 User Flow
↓
再從 Flow 回推 Pages

這是文章的 Exploration Order，跟 ClarifyBuild 正式的 Generation Pipeline 屬於兩個不同層次：後者要怎麼從 Clarification Result 推導 Scope、User Flow、Pages、Functional Requirement、User Story 和其他 Specification 內容，還需要再設計。

現在太早把這個順序鎖死，反而又可能變成另一種過早決策。

今天 ClarifyBuild 又前進了一點

今天依然沒有寫 HTML、CSS 或 JavaScript。

但 ClarifyBuild 本身並不是沒有進度。

今天至少把幾件事情釐清了。

第一，正式區分：

ClarifyBuild Usage Flow

和：

Target Project User Flow

前者描述 ClarifyBuild 自己怎麼被使用。

後者則是 ClarifyBuild 未來要幫使用者產生、放進 Project Specification 的目標產品流程。

第二，重新確認：

Clarification Flow

是 Usage Flow 裡展開得更細的需求釐清流程，而不是另一份重複的產品流程。

第三，ClarifyBuild MVP 的主要 Page / View 暫時收斂成：

Landing
Builder
Spec Preview
Prompt Preview

其中：

• Export 改為 Action，不獨立成 Page。
• Idea、Clarification、Scope 優先放在同一個 Builder 裡，以不同 State 呈現。

所以目前 ClarifyBuild 已經慢慢從：

Idea
↓
Clarification
↓
Specification
↓
Prompt

展開成一個更能實際落地的產品結構。

下一個問題：知道怎麼走之後，還知道「為什麼」嗎？

現在 User Flow 已經可以告訴我：

使用者從哪裡開始
↓
做什麼
↓
去哪裡
↓
最後完成什麼

但還少了一件事情。

例如：

使用者可以 Export Markdown。

這句可以描述「他能做什麼」。

但還沒有回答：

他是誰？
他為什麼需要這個功能？
這件事到底替他解決什麼問題？

所以接下來，我想繼續整理 Requirement Engineering 裡另一個常見的概念：

User Story

也就是從：

系統要提供什麼功能？

再往前追問：

誰需要這個功能？
為什麼？

Day 8 完成。

明天見。